A file system (FS) store files and stores information about files. The information stored in files may be referred to as data. The information about files may be referred to as metadata. The metadata may include, for example, a file name, a file size, a file parent, a file descendant, a file access time, a file owner, file permissions, an address where the file can be found, and other information. Some of the metadata for an individual file may be stored in a data structure known as an inode. An inode may provide a connection between a logical space associated with the FS and physical hardware that supports the FS. The inodes and metadata for a file system may also be stored collectively. The metadata has both structure and content. When the data in a file or about a file changes, an FS may want to update the metadata about that file. For example, if the contents of a file are changed, the FS may want to memorialize the time at which the change was made and by whom the change was made. Actions on a file produce actions on a corresponding inode. Inode is used herein in its computer science and operating system usage.
An FS may experience an action that affects a member of its collection of files. The action may be recorded in a transaction. For example, a transaction may be generated when a file is created, accessed, updated, or deleted. FS metadata and transactions that affect the FS may be recorded or otherwise preserved for the FS. To mitigate issues associated with an error on the machine on which the FS is running or with a process associated with the FS, the metadata or transaction may be stored on a separate device or in a separate memory or database. For example, an FS may cause FS metadata to be sent to a storage manager, metadata manager, metadata dump, or other location. Additionally, the FS may cause a stream of FS transactions to be sent to a data store (e.g., updates database) that stores FS transactions. In one embodiment, the stream of FS transactions may arrive at the updates database indirectly through the metadata manager. The metadata and FS transactions may include inode information including, for example, information that resolves to an actual disk address at which the file may be accessed. When an inode provides information that resolves to an actual disk address, then the inode information may have limited value due to synchronization issues. Independently run file systems may each have their own copy of metadata content. The independently run file systems' own copies of metadata content may reference the same shared copy of file content. Inodes are local to a FS. They are a private resource of a FS. Thus, actions performed on a file in a FS produce actions on a corresponding inode associated with that individual FS. A conventional inode may have a field or fields (e.g., length field, offset field) that resolve to an actual disk address. When the inode resolves to an actual disk address, then the metadata or transactions that are stored off the machine for which the actual disk address is meaningful may be tightly bound to the originating FS and to the actual disk address. This may complicate the ability to share data between file systems, to create a new FS from an existing file system, or even to recreate or rebuild a new version of an FS from the stored metadata or transactions.
Conventionally, an inode is a data structure that is used to represent a filesystem object. The filesystem object can be one of various things including a file or a directory. Conventional inodes store the attributes and disk block location(s) of the filesystem object's data. Filesystem object attributes may include manipulation metadata (e.g., change, access, modify time), as well as owner and permission data (e.g., group-id, user-id, permissions).
Originally, an FS stored and organized data for a single operating system or machine. The files associated with the FS may have been stored on a tape, on a disk (e.g., floppy disk, hard disk), or on another device local to the machine on which the FS ran. In the early days of computing when operating systems and file systems were being developed, there were no networks, no shared memory, and no shared devices. Therefore, file systems developed from the point of view of a single observer and user. The inode therefore also developed from the point of view of a single user and single device that had its own local, dedicated storage. This paradigm of a single user, a single FS, and a single device with dedicated local storage led to file systems using local namespaces exclusively and storing actual addresses in inodes. Namespace, as used herein, refers to its usage in computer science where a namespace is considered to be a container for a set of identifiers. The identifiers may also be known as symbols or names. A namespace provides a level of direction to specific identifiers which makes it possible to distinguish between identifiers with the same name. As networks and shared memory and shared storage devices were created and proliferated, shortcomings in the inodes associated with the single user, single FS, single device paradigm emerged.